<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Tasking产出的Task和AC有什么差别？</title>
    <meta content="1200" property="og:image:width"/>
    <meta content="630" property="og:image:height"/>
    <link rel="icon" href="../../img/icon.png">
    <link as="font" crossorigin="" href="../../Agrandir-Heavy.2fd076131b76.woff2" rel="preload"
          type="font/woff2"/>
    <link as="font" crossorigin="" href="../../Agrandir-Bold.5adcade67872.woff2" rel="preload"
          type="font/woff2"/>
    <link as="font" crossorigin="" href="../../source-sans-pro-v14-latin-regular.899c8f78ce65.woff2"
          rel="preload" type="font/woff2"/>
    <link as="font" crossorigin="" href="../../Agrandir-Regular.11a4ceb99823.woff2" rel="preload"
          type="font/woff2"/>
    <link as="font" crossorigin="" href="../../source-sans-pro-v14-latin-600.c85615b29630.woff2" rel="preload"
          type="font/woff2"/>
    <link href="../../common.0016184b0568.css" rel="stylesheet" type="text/css"/>
    <link href="../../home.a12d472bcf09.css" rel="stylesheet" type="text/css"/>
    <link href="../content-page.css" rel="stylesheet" type="text/css"/>
</head>
<header class="site-header">
    <br/>
    <h1 style="margin: 0 auto;text-align: left;margin: 0 50px;color: white;font-size: 3.5rem">
        <img src="../../svg/icon-white.svg" height="80" width="80"/>&nbsp;&nbsp;Neil's wiki
        <button class="subscribe" onclick="location.href='../subscribe/index.html'">Subscribe</button>
    </h1>
    <br/>
</header>
<body class="content-body">
<div class="content-body-class">
    <h1 class="hosting-pricing-plan-block__header">Tasking产出的Task和AC有什么差别？</h1>
    <div class="content-infos">
        <div class="content-words">
            回答这个问题之前，我们先统一两个术语的上下文：
        </div>
        <div class="content-list">
            1. Tasking，开发人员对User Story的拆分。
        </div>
        <div class="content-list">
            2. AC，Acceptance Criteria，User Story的验收标准。
        </div>
        <div class="content-words">
            在ThoughtWorks敏捷交付团队中，业务需求的载体是User Story（用户故事，极限编程中的一项实践，平时我们内部都简称为Story），AC是User
            Story的一部分。所谓AC，即是用户故事的验收标准的定义，验收什么？验证系统功能是否满足业务需求，并决定要不要接收该功能上线。
        </div>
        <div class="content-words">
            比如，用户登录的User Story，其中一个AC这么写的：
        </div>
        <div class="content-unlist">
            • Given 用户名和密码都正确
        </div>
        <div class="content-unlist">
            • When 用户登录
        </div>
        <div class="content-unlist">
            • Then 登录成功，跳转到个人主页
        </div>
        <div class="content-words">
            你开发的系统，用户使用正确的用户名和密码登录后，能成功登录，并且登录后能跳转到个人主页，则说明这个业务需求已经被满足了（我们也说这个AC通过了），表示客户可以验收这个功能了，否则表示功能未开发完。
        </div>
        <div class="content-words">
            所有的AC都满足后表示该User Story完成，可以准备进入QA测试环节了。
        </div>
        <div class="content-words">
            统一了这个术语后，再说点实际的。在ThoughtWorks，很多交付团队的BA（Business Analyst，业务分析师）在编写User Story的AC的时候会采用上述的Give When
            Then三段式去描述，当然也有不用这种格式（Free Style）的BA。不论其用什么形式去描述，作为一个合格的BA，她在定义User
            Story的AC的时候，一定是在定义用户不同的业务场景下行为结果。简单地说，就是对业务需求的场景拆分，优秀的BA可能更喜欢对拆分后的场景进行实例化。
        </div>
        <div class="content-words">
            比如上述的用户登录User Story，可能还会有其他两个AC（具体有几个，取决于真实的业务需求）：
        </div>
        <div class="markdown">
            Given 用户名不存在<br/>
            When 用户登录<br/>
            Then 登录失败，登录页面提示用户名不存在
        </div>
        <div class="markdown">
            Given 用户密码错误<br/>
            When 用户登录<br/>
            Then 登录失败，登录页面提示密码错误
        </div>
        <div class="content-words">
            当然还会配一些界面原型来告知开发人员错误信息显示的位置和样式（一图抵千言，可视化的效果）。
        </div>
        <div class="content-words">
            如果你碰到一个这样的BA，恭喜你，你很幸运，她已经将业务场景拆分得很细致，你只需要按照AC来来进行节奏的开发就好了。你对User Story进行Tasking的结果可能跟AC很类似。
        </div>
        <div class="content-words">
            但很多时候，你没有这么幸运，比如说BA定义AC的时候粒度较粗，或者描述AC格式五花八门，而你又不好意思或者因为客观限制没法时刻找到BA做澄清。这个时候你就可以对User
            Story进行Tasking，并将结果可视化出来，然后找BA和QA（QA有天然的极端边界视角）去确认你对需求细节的理解。这个确认过程可以带来如下好处：
        </div>
        <div class="content-list">
            1. 获得对需求理解的反馈，避免需求理解偏差而做无用的开发工作。
        </div>
        <div class="content-list">
            2. 帮助BA完善需求细节，可能她自己一开始也遗漏了一些边界场景。
        </div>
        <div class="content-list">
            3. 帮助提升BA的个人技能，以一种良好定义格式的Tasking结果，可以作为一些新BA定义AC的模板示例。
        </div>
        <div class="content-words">
            所以这个时候你的Tasking结果可能会跟AC不一样了。会比AC更为细粒度，更有利于去做开发，更有利于定义完成的标准，减少没必要的返工。
        </div>
        <div class="content-words">
            总而言之，在敏捷交付团队中，针对User Story的Tasking和AC，宗旨都是对业务场景的细化和定义，带来的的价值是类似的，只不过说可能AC更多的是BA来定义。
        </div>
        <div class="content-addition">
            文章转载自<a href="https://xpbootcamp.cn/tdd/questions/012">袁慎建</a>
        </div>
    </div>
</div>
</body>
</html>
<div class="back-to-home-page">
    <a class="call-to-action__link button" href="/">返回首页</a>
</div>
